The Internet's successful performance is due to the IP architecture's robustness, flexibility and ability to scale. This success is not based upon on the Internet's efficiency, optimization, security, content protection, fine-grained control or performance guarantees. Furthermore, IP data networks enabling the delivery of content (e.g., audio, video, e-books) everywhere around the globe were not designed to protect content from illegal and unintended use.
1. Field and Context of the Invention
The field of the invention involves assuring that trusted operation is guaranteed and validated by the underlying methods and systems. In particular, communications are assured of trusted flow; specifically, making sure that the end stations and users of a computer network operate correctly under given and known rules of transmission—even though protocols, methods and software logic are typically available to users of such networks. A trusted operation is one by which performance complies with its allowed and defined specifications.
A trusted operation will assure network elements that stations perform their task as known and as determined by a service agreement. It will assure servers in networks that users are behaving properly and are not over using content beyond the agreed upon license.
The trusted operation involves mechanisms for signaling of various purposes, e.g., authentication of stations and users. Additionally, these mechanisms involve communication network software, communication network operation, control and management. They further involve cryptographic systems, functions, and software transformation e.g. obfuscation operation. Computing hardware and software systems are intrinsic elements of the Internet; therefore, they lie within the field of the invention.
In general, the underlying mechanisms assure that a “combined functionality” takes place within a computing system. Part of this “combined functionality” is a crucial function of the underlying computing system, whereas another part of the “combined functionality” is a method to generate an unpredictable signal. The mechanisms assure interlocking of the parts into the combined functionality, whereas, locking is defined by the combined performance of all parts. The operation part, factored into the “combined functionality,” is trusted (and is typically associated with limitations, e.g., rate of operation or number of times before renewal of precondition for next sub-operation). The checking is accomplished by verifying a signal's performance. If the signal passes the check, it means that the other (operation) part was performed subject to the associated limitation—namely, a trusted one.
The operation involves a trusted flow of packets (or other units of measurement as defined by communication fields), associated with rules of transmission. E.g., a TCP connection is associated with a window size that allows a maximum number of transmissions. A trusted flow implies that the end station conforms to the allocated window size. However, there is no way to impose compliance with the assumed parameters on users and end stations to be “trusted,” since parameters can typically be easily changed.
One aspect of the present invention involves the “interlocking” of parts and insistence that one part will “signal,” and its checking will assure compliance by adding a checking function to validate signals. Thus, if a TCP program with the currently correct performance parameters (e.g., rules of transmission) is interlocked with a cryptographic pseudo-random generator (with a random seed) by which output cannot be predicted; if further, the checker has a copy of the pseudo-random generator; if further, the output of the pseudo-random generator is put on data packet headers; if further, the headers are checked and their content matches the expected value from the generator, then the checker concludes that the packet flow is “trusted.”
The basic mechanisms involve a system where the “combined functionality” is performed and one where it is checked. It also involves a communication system; a software transformation module to assure the interlocking of the separate functions into a combined functionality; and finally, a management system assuming plurality of elements implementing the combined functionality is in the network.
One of the main applications of the disclosed invention is in Digital Right Management (DRM)—or Content Management (CM). DRM is a set of technologies that content owners can use to protect their copyrights while providing it to customers. In most cases, DRM/CM is a system that encrypts digital media content and limits access to only those people who have acquired a proper license/permission to play/use the content. Specifically, DRM/CM is a technology that enables the secure distribution, promotion and sale of digital media content on the Internet. A DRM/CM proper license/permission to play/use the content may include restrictions on use after delivery, e.g., no copying and printing, limited number of plays, time limits, no forwarding and so on.
An example of a DRM/CM issue—an e-book—can be delivered over the Internet using standard cryptographic techniques. However, if the recipient can save the e-book in an unrestricted form, he can then freely redistribute copies everywhere. This fear has led publishers to largely forego the potentially lucrative sale of digital books and has had a similar chilling effect on the legitimate distribution of other types of digital content.
Consequently, DRM/CM deals with how to project Policy Expressions with Confidence into Remote Environments. In addition to authoring and evaluating policy expressions, a DRM system operating across multiple nodes in a network must be able to accomplish a third important task: projecting policy to remote nodes with confidence that the policy will be respected. Fear about platform behavior is an anathema to the distribution of information, and such fear is rampant today across all segments of potential DRM users. Owners of digital content will not distribute their works to platforms they consider to be “hostile” (or potentially so), and the same is true of individual users who are requested to reveal private information to remote systems. Every content owner needs some way to be convinced that the remote system receiving his or her valuable information will behave as the owner expects—ultimately meaning that the remote system will implement the policy that the content owner has defined and associated with his content.
A DRM/CM system on the (remote) PC will integrate with a broad range of hardware devices. Additionally, some special hardware device may be able to take part in the DRM content chain. However, in this present invention the use of special hardware may not be necessary.
Hardware devices have to implement DRM/CM functionalities, e.g.: tamper resistance (obfuscation, anti-debugging measures), authentication ensuring only trusted components in the process (components must be signed), and authentication periodically checking for signed components. However, hardware solutions have limitations, e.g.: (1) incompatibility with installed base of PCs, players, (2) time and expense to build an installed base, (3) long lifecycles requiring devices to remain secure for years, and (4) field Upgrades which are difficult and costly to replace when hardware is compromised.
Dynamic DRM/CM systems are used to manage and authorized a wide range of operation on content, e.g.: copy, delete, modify, embed, execute, export, extract, annotate, aggregate, install, backup, loan, sell, give, lease, play, print, display, read, restore, transfer, uninstall, verify, save, obtain, issue, and possess and revoke content. Furthermore, dynamic DRM/CM systems are used to manage and authorized: restrict grant of rights to certain time periods, locations, devices, users, purposes, qualities of the content and so on.
Another aspect of DRM/CM is to ensure secure distribution of the content and enforce conditional access to it. In particular, the system should prevent pirates from obtaining free versions of the original master copy or copies received by end-users. More precisely, the very high value of the content and the possible financial impact of even a single act of piracy require the system to keep piracy rates significantly below the levels of traditional content protection systems. (Piracy rates for most broadcast TV systems lie between 3% and 10%.) The goal of DRM/CM is to increase the robustness of the system by making use of other properties of the environment: (1) raising the cost of the initial attack by means of tamper-resistant hardware, (2) making pirates identifiable and (3) enabling cheap and easy renewal of the system. After a compromise has been detected, the system must prevent the compromised projectors from receiving new content. Generally, even in the absence of a compromise, the security components of the projectors should be renewed (changed) periodically, in order to present a moving target to potential attackers.
2. Background of the: Prior Art
One of the ways to specify the requirements of Digital Right Management (DRM) or Content Management (CM) is to use XrML rights language [‘XrML: Extensible Rights Markup Language,’ http://www.xrml.org]. XrML provides the rights—specification language for implementing DRM/CM owned by some content guard mechanism. XrML allows the specification of various rights and licenses on to use/consume various content. The XrML rights language has the following guiding principles: (1) Enable rapid growth of the eContent industry for all media, (2) Enable XrML to meet the needs of all stakeholders in the eContent industry, (3) Establish a community of practice that is committed to develop a common rights language for use by trusted systems, (4) Enable interoperability across multiple platforms and content types, (5) Encourage interested parties to submit and share XrML Modifications with the community of practice that will extend and enhance the XrML Specifications, (6) Enable future XrML enhancements and modifications to meet the needs of the DRM community, and that the standard does not become fragmented or create commercial advantage for any single party, (7) Establish a XrML Panel of knowledgeable and interested parties, to review the XrML Modifications and make recommendations concerning incorporation of XrML Modifications in the XrML Specifications and (8) This License Agreement does not apply to, dictate or restrict General-purpose APIs (Application Program Interfaces), operating system functions and specifications, or other software that incorporate XrML Specifications.
In the context of XrML, “Digital Rights Management” or “DRM” means techniques, processes, procedures and algorithms related to establishing an environment that utilizes syntactically expressed declarative statements having an environment-wide meaning for the management of digital rights; includes computer hardware and software which enable or implement: trusted licensing, secure rights and permissions specification, rights and permissions enforcement, establishment of a trusted computing environment, and trusted infrastructure, each for: (i) the secure preparation, transmission, prevention of misuse and/or consumption of protected digital works by authorized licensees (e.g., watermarking and fingerprinting and software obfuscation) and (ii) secure digital commerce transactions occurring over internal and external computer networks, including the automated and persistent enforcement of policies for consumption of digital goods, usage tracking, budget management, fraud detection, account management, key management and similar functions.
XrML provides for describing specifications of rights, fees and conditions for using digital contents (or properties), together with message integrity and entity authentication within these specifications. It is intended to support commerce in digital contents, e.g., publishing and selling electronic books, digital movies, digital music, interactive games, computer software and other creations distributed in digital form. It is also intended to support specification of access and use controls for secure digital documents in cases where financial exchange is not part of the terms of use. XrML documents are XML conforming—they are readily viewed, edited, and validated with standard XML tools. The use of XrML for usage rights on digital contents is to ensure that trusted systems are able to exchange digital contents and interoperate. Trusted systems (or repositories) are systems that can hold digital contents and which can be trusted to honor the rights, conditions and fees specified for digital contents. In document commerce, trusted systems are for authoring, playing, and selling digital works. They include personal systems, on-line storefront systems, library systems, and others.
An extensive discussion on DRM can be found in “Digital Rights Management: Business and Technology,” William Rosenblatt, William Trippe and Stephen Mooney, 300 pp., ISBN: 0-7645-4889-1. Hungry Minds, Inc., Indianapolis, Ind., November 2001. Discussion on trusted computing in general and its relevance to DRM can be found in (1) “A Trusted Open Platform,” Paul England, Butler Lampson, John Manferdelli, Marcus Peinado, and Bryan Willman, IEEE Computer, July 2003, pp. 55-62; and (2) “TCPA PC Specific Implementation Specification,” Version 1.00, Sep. 9, 2001—is The Trusted Computing Platform Alliance Specification, V1.1 (http://www.trustedpc.org) has been written as a platform independent document to enhance trust on computing platforms (as such, the TCPA Specification is general in specifying both hardware and software requirements).
Our methods use cryptographic functions, e.g., pseudo-random generation, random bits generation, authentication, signature and encryption. Such methods of varied level of security and efficiency are known in the art, in software packages and in hardware devices. We can employ them as needed in our mechanisms. A security professional who is familiar with the art will be able to use the cryptographic functions and tools and embed them in our invention. Such mechanism are described in “Applied Cryptography: Protocols, Algorithms, and Source Code in C,” 2nd Edition by Bruce Schneier; Publisher: John Wiley & Sons; ISBN: 0471117099; 2 edition (Oct. 18, 1995) and in “Handbook of Applied Cryptography” (CRC Press Series on Discrete Mathematics and Its Applications) by Alfred J. Menezes, Paul C. Van Oorschot, Scott A. Vanstone (Editor); Publisher: CRC Press; ISBN: 0849385237; (October 1996).
The same is true for underlying devices: we can employ such devices as smart cards and other portable devices (e.g., USB connection based, wireless devices with radio frequency, laser connection, etc.). A security engineer who is familiar with the art and the common practice will be able to employ these elements and embed them in our invention.
The method uses hidden programs. Software obfuscation transformation is one method to hide programs. Methods and techniques for obfuscation are also known in the art. They modify the “look” of the software logic, but maintain its “semantics” (or meaning). They are analogous to compiling a program in high-level language code to a program in “object code” or “machine code” which performs the same task but is not readable to most users. They make the software “unreadable” and “non-modifiable.” In fact, there are various methods in the art applied to the currently most useful programming languages. The methods take a software program (e.g., written in the Java language) and return another program (in Java as well) which performs the same task and approximately with the same performance. Yet, the second program is hard to read and understand. The art of program obfuscation, including all transformations on data, variables, names, control structure, etc. are given in a number of papers considered the state of the art by C. Collberg C. Thomborson and D. Low: ‘Manufacturing Cheap, Resilient and Stealthy Opaque Constructs,” ACM's POPL 1998, pages 184-196; and “Watermarking, Tamper-Proofing, and Obfuscation—Tools for Software Protection,” by Collberg, Thomberson and Low, technical report University of Arizona to be published in IEEE Transactions on Software Engineering 2002; and “A Taxonomy of Obfuscation Transformation,” by C. Collberg, technical report number 148, University of Arizona.
Additionally, Valdez and Yung describe how to add encryption operation and program distribution to obfuscation in: “Software DisEngineering: Program Hiding Architecture and Experiments,” by E. Valdez and M. Yung, Information Hiding 1999, pages 379-394, Springer Verlag Lectures in Computer Science; and “SISSECT: DIStribution for SECurity Tool,” by E. Valdez and M. Yung, ISC 2001, pages 125-143, 2001 Springer Verlag Lectures in Computer Science LNCS2200, respectively. Note that the embedding of programs inside tamper-proof devices and hiding encrypted programs are also known in the art (e.g., as part of cryptographic co-processors). In our mechanisms we use a combination of the above techniques.
Note that hidden programs have been traditionally employed to hide the logic of the software. They have been used in hiding cryptographic programs (e.g., in a tamper-proof device) so that the operation is not observable or modifiable. They have been further used to enforce certain operations associated with content distribution and electronic commerce in order to assure that such operations (e.g., digital payment and protecting of content) are run in environments which are not modifiable by the user. Again, the notion of use is against modification of the working environment.
Unlike the use of hiding and obfuscation of programs for the sake of software protection, the present invention does not hide the “semantics of the program” from the user. In fact, the specification and performance parameters can be publicly known. The goal is, in turn, an integrity function, where the goal is for users not to be able to change the operation software (that performs data packet transmission) while retaining correct signaling.
What is needed is a mechanism that combines many programs together so that they are inseparable. In this sense, hidden programs are merely a means to get a method of “interlocking mechanism” where known (rather than unknown) programs and perhaps parameters (hidden) are combined into a unique functionality and are inseparable. The interlocking involves putting together a set of “well behaved” programs with correct and agreed upon parameters by a continuous mechanism for signaling, and associating the signaling checker with a method that assures good behavior of the continuous flow. One aspect of the present invention involves system programs, which are commonly known, programs that perform packet generation and performance parameters and even known cryptographic programs with hidden parameters. A method is provided in accordance with the present invention, where it is impossible via hidden programs to execute parts of the combined functionality separately with a malicious non-trusted part replacing another part of the combined functionality.
Also in accordance with the present invention, a mechanism for checking compliance for the signals, as well as a combined communication system mechanism for handling the trusted flow coming from stations that use the combined functionality. This will give network elements that can assure trusted traffic is generated in a trusted fashion and further is validated. In addition, required methods and systems employing the above elements in a combined network and that will manage, renew and tune the elements in the invention. A method for dynamically changing hidden programs and parameters and for renewing preconditions is also required. Also in accordance with the present invention, a method is provided for generating and distributing the combined functionality logic modules, a mechanism for safe integration of separate known logic modules to the combined functionality logic.